home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Tricks of the Mac Game Programming Gurus
/
TricksOfTheMacGameProgrammingGurus.iso
/
More Source
/
Libraries
/
VideoToolbox 95.04.18
/
Notes
/
GWorld baseAddress.note
< prev
next >
Wrap
Text File
|
1993-12-15
|
7KB
|
130 lines
Note from Apple.
Macintosh GWorld baseAddresses
How can I transform the content of a GWorld on a NuBus™ card? The idea is to
clone the GWorld, copy the data to the card, transform them, patch the address
into the GWorld, and display them directly on the screen. I´d like to do it in
a way that works well with the 8•24 GC and similar asynchronous QuickDraw
stuff.
___
NewGWorld allocates off-screen buffers simply by using the same Memory Manager
calls that you and I make. To actually allocate the memory it simply calls
NewHandle to allocate the buffer in your application’s heap if you have the
useTempMem (née useMFTemp) bit clear. It then tries to move it as high in your
heap as possible by calling MoveHHi. If you have the useTempMem bit set, then
NewGWorld uses the temporary memory calls to allocate the off-screen buffer in
temporary memory, and then it tries to move it as high as possible in the
temporary memory space. That’s really all there is to it. The GWorld’s PixMap,
GDevice and CGrafPort are allocated similarly—they’re all allocated in your
heap using regular Memory Manager calls with no special options, patches, or
other nefarious tricks.
None of this changes when you have the 8•24 GC software active—all memory is
allocated out of your application’s heap. Once you start drawing into the
GWorld, though, the GC software can copy the parts of a GWorld to the 8•24 GC
memory. The GWorld and its parts go still occupy your heap’s memory though,
regardless of whether it’s cached on the 8•24 GC card or not.
If you have a NuBus card with gobs of memory, NewGWorld can’t take advantage
of it because the Memory Manager calls that it uses can’t allocate memory on
NuBus memory cards. There are no options to NewGWorld or any other GWorld
calls that let you say, “there’s lots of memory over on this NuBus card, all
for you.” That means that GWorlds aren’t appropriate if you want to have
control over where the off-screen buffer is allocated. Conceivably, you could
allocate a GWorld, stuff the address of your NuBus memory card into the
baseAddr of your GWorld’s PixMap, and then put the constant baseAddr32 into
its pmVersion field, but engineering here didn’t feel very comfortable with
that idea because of compatibility concerns.
QuickDraw is the only thing that’s supposed to know how GWorlds are
constructed. We know that they’re CGrafPorts and we can get their PixMap,
GDevice, and off-screen buffer, but we can’t make any assumptions about how
they were allocated and where they are. For example, we know that the off-
screen buffer is allocated as a handle now, but that won’t necessarily be the
case in the future. There’s no guaranteed way to tell which way it was
allocated, or even if NewGWorld uses the Memory Manager to allocate it at all
(which it always does currently of course). Even the GWorld’s CGrafPort is
allocated as a handle which just happens to be always locked. If you try to
dispose of a GWorld in which you’ve modified the baseAddr, you’ll need
DisposeGWorld to make sure everything is deallocated properly, but it’ll act
unpredictably when it tries to deallocate the off-screen buffer.
So if you want to use the memory on your NuBus memory card, you’re going to
have to create your own PixMap, color table (if it needs one), GDevice, and
CGrafPort. Technical Note #120, “Drawing Into an Off-Screen PixMap” covers
creating your own PixMap, CGrafPort, and color table, but it has the same
depth and equivalent color table to the screen, so it just steals a screen’s
GDevice. I think it’s always a good idea to create your own GDevice when you
draw off screen. If you use a screen’s GDevice, then you have to depend on
that GDevice’s depth and color table. By creating your own GDevice, your off-
screen drawing can use any depth and color table you want at any time, and
Color QuickDraw won’t choke.
To create your own GDevice, it’s better not to use NewGDevice because it
always creates the GDevice in the system heap, and it’s just better to keep
your own data structures in your own heap. Here’s what you should set each of
its fields to be:
gdRefNum - Your GDevice has no driver, so just set this to zero.
gdID - It doesn’t matter what you set this to; might as well set it
to zero.
gdType - Set this to 2 if your off screen uses direct colors (16 or
32 bits per pixel) or 0 if your off screen uses color table
(1 through 8 bits per pixel).
gdITable - Allocate a small (maybe just 2-byte) handle for this field.
After you’re done setting up this GDevice and your off-screen
PixMap, color table (if any) and CGrafPort, then set this
GDevice as the current GDevice by calling SetGDevice, and then
call MakeITable, passing it NIL for both the color table and
inverse table parameters, and 0 for the preferred inverse
table resolution.
gdResPref - I’d reckon that more than 99.9% of all inverse tables out
there have a resolution of 4. Unless you have some reason not
to, I’d recommend the same here.
gdSearchProc - Set to NIL. Use AddSearch if you want to use a SearchProc.
gdCompProc - Set to NIL. Use AddComp if you want to use a CompProc.
gdFlags - Set to 0 initially, and then use SetDeviceAttribute after
you’ve set up the rest of this GDevice.
gdPMap - Set this to be a handle to your off-screen PixMap.
gdRefCon - Set this to whatever you want.
gdNextGD - Set this to nil.
gdRect - Set this to be equal to your off-screen PixMap’s bounds.
gdMode - Set this to -1. Why? I’m not sure. This is intended for
GDevices with drivers anyway.
gdCCBytes - Set to 0.
gdCCDepth - Set to 0.
gdCCXData - Set to 0.
gdCCXMask - Set to 0.
gdReserved - Set to 0.
For gdFlags, you should use SetDeviceAttribute to set the noDriver bit and the
gdDevType bit. You should set the gDevType bit to 1 even if you have a
monochrome color table. The 0 setting was only used for the days when
monochrome mode was handled by the video driver, which 32-Bit QuickDraw
eliminated. Your GDevice doesn’t have a driver anyway.
One last warning is that you should set the pmVersion field of your PixMap to
be the constant baseAddr32 (equals 4). That tells Color QuickDraw to use 32-
bit addressing mode to access your off-screen buffer, and that’s a requirement
if your off-screen buffer is allocated on a NuBus card.
©Apple Computer, Inc. 1985-1991